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The University of Houston-Clear Lake established the Research Institute for 
Computing and Information systems in 1986 to encourage NASA Johnson Space 
Center and local industry to actively support research in the computing and 
information sciences. As part of this endeavor, UH-Clear Lake proposed a 
partnership with JSC to jointly define and manage an integrated program of research 
in advanced data processing technology needed for JSC's main missions, including 
administrative, engineering and science responsibilities. JSC agreed and entered into - 
a three-year cooperative agreement with UH-Clear Lake beginning in May, 1986, to 
jointly plan and execute such research through RICIS. Additionally, under 
Cooperative Agreement NCC 9-16, computing and educational facilities are shared 
by the two institutions to conduct the research. 

The mission of RICIS is to conduct, coordinate and disseminate research on 
computing and information systems among researchers, sponsors and users from 
UH-Clear Lake, NASA/JSC, and other research organizations. Within UH-Clear 
Lake, the mi ssion is b eing implemented through interdisciplinary involvement of 
faculty and students from each of the four schools: Business, Education, Human 
Sciences and Humanities, and Natural and Applied Sciences. 

Other research organizations are involved via the “gateway” concept. UH- Cle ar 
Lake establishes relationships with other universities and r esearch orga nizations, 
having common research interests, to provide additional sources of expertise to 
conduct needed research. 

A major role of RICIS is to find the best match of sponsors, researchers and 
research objectives to advance k nowledge in the computing and information 
sciences. Working jointly with NASA/JSC, RICIS advises on research needs, 
recommends principals for conducting the research, provides technical and 
administrative support to coordinate the research, and integrates technical results 
into the cooperative goals of UH-Clear Lake and NASA/JSC. 
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Abstract 

Due to the Ada mandate of such government agencies 
as DoD, NASA and FAA, interest in deploying expert 
systems in Ada has increased. Recently, a couple of 
Ada-based expert system tools have been developed. 
According to recent benchmark reports, these tools do 
not perform as well as similar tools written in 
C. While poorly implemented Ada compilers also con- 
tribute to the poor benchmark result, some fundamen- 
tal problems of the Ada language itself have been un- 
covered. In this paper, we describe Ada language 
issues encountered during the development of ART- 
Ada, an expert system tool for Ada deployment. 
ART-Ada is being used to implement several expert 
system applications for the Space Station Freedom 
and the U.S. Air Force. 

1. Introduction 

As the government mandate to standardize on Ada 
as the language for software development is being ac- 
tively enforced by government agencies, including 
DoD, NASA and FAA, interest in making expert sys- 
tems technology readily available in Ada environ- 
ments has increased. An example project that ex- 
hibits the need for expert systems in Ada is NASA’s 
Space Station Freedom. Another large-scale applica- 
tion of Ada-based expert systems is the Pilot’s As- 
sociate (PA) project for military combat aircraft [10]. 


Recently, several Ada-based expert system tools 
have been developed to address this need of govern- 
ment agencies. Commercial off-the-shelf (COTS) 
tools include: 

• ART-Ada [19], [20], [21], 

• CHRONOS [22], and 

• CLIPS/Ada [1], [2], [28]. 

There are several other experimental systems 
reported mainly in the proceedings of the annual con- 
ference on artificial intelligence Sc Ada (AIDA), 
1987-1989 [26], [29], [9], [16], [6], [18]. 

Since ART-Ada and CLIPS/Ada are modeled after 
C-based tools, ART-IM and CLIPS respectively, they 
are based on the same algorithm as that of C-based 
tools. According to recent benchmark 

reports [28], [17], Ada-based tools do not perform as 
well as C*based ones. While poorly implemented Ada 
compilers also contribute to the poor benchmark 
result, some fundamental problems of the Ada lan- 
guage itself have been uncovered. 

In this paper, we describe Ada language issues en- 
countered during the development of ART-Ada, an 
expert system tool for Ada deployment [19], [20], [21]. 
ART-Ada allows applications of a C-based expert sys- 
tem tool called ART-IM to be deployed in various 
Ada environments. 


This paper will appear in the proceedings of TRI-Ada, Baltimore, Maryland, December 1990. 
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Figure 1-1: Overall Architecture of ART-Ada 


2. ART-Ada 

Inference has been involved with Ada-based expert 
systems research since 1986. Initial work centered 
around a specification for an Ada-based expert system 
tool [llj. In 1988, the ART-Ada Design Project was 
initiated to design and implement an Ada-based ex- 
pert system tool [13], [19], [20]. At the end of 1989, 
ART-Ada was released to beta sites as ART-Ada 2.0 
Beta on the V AX/VMS and Sun/Unix platforms [14]. 
In 1990, eight beta sites, four NASA sites and four 
Air Force sites, have been evaluating ART-Ada 2.0 by 
developing expert systems and deploying them in Ada 
environments. ; ----- - 


Inference Corporation developed an expert system 
tool called ART (Automated Reasoning Tool) that has 
been commercially available for several years [12]. 
ART is written in Common Lisp and it supports 
various reasoning facilities such as rules, objects, 
truth maintenance, hypothetical reasoning and object- 
oriented programming. In 1988, Inference introduced 
another expert system tool called ART-IM 


(Automated Reasoning Tool for Information Manage- 
ment), which is also commercially available [15]. 
ART-IM is written in C and it supports a major sub- 
set of ART's reasoning facilities including rules, ob- 
jects, truth maintenance and object-oriented program- 
ming. ART-IM supports deployment of applications 
in C using a C deployment compiler that converts an 
application into C data structure definitions in the 
form of either C source code or object code. ART- 
IM's interactive development environment includes a 
graphical user interface that allows browsing and 
debugging of the knowledge base and an integrated 
editor that offers incremental compilation. ART-IM 
is available for MVS, VMS, Unix, MS-DOS, and OS/2 
environments.. 

Our approach in designing an Ada-based expert sys- 
tem tool was to use the architecture of proven expert 
system tools: ART and ART-IM. Both ART and 
.ART-IM have been successfully used to develop many 
applications which are in daily use today [4], [5], [7], 
[23], [24], [25], [27]. ART-IM was selected as a 
baseline system because C is much closer to Ada than 
Lisp. While ART-IM’s inference engine was 




reimplemented in Ada, ART-IM’s front-end (its 
parser/analyzer and graphical user interface) was 
reused as the ART-Ada development environment. 
The ART-IM kernel was enhanced to generate Ada 
source code that would be used to initialize Ada data 
structures equivalent to ART-IM’s internal C data 
structures, and also to interface with user-written Ada 
code. This approach allows the user to take full ad- 
vantage of an interactive development environment 
developed originally for ART-IM. Once development 
is complete, an application is automatically converted 
to Ada source code. It is, then, compiled and linked 
with the Ada runtime kernel, which is an Ada-based 
inference engine. 

The overall architecture of ART-Ada is depicted in 
figure 1-1. The knowledge base is developed and 
debugged using an interactive user interface that sup- 
ports three main features; a command loop similar to 
the Lisp eval loop, a graphical user interface for 
knowledge base browsing and debugging, and an in- 
tegrated editor for the incremental compilation of the 
knowledge base. Any user-written Ada code can be 
integrated into the knowledge base by either calling it 
from a rule or invoking it as a method for object- 
oriented programming. 

Once the knowledge base is fully debugged, it can be 
automatically converted into an Ada package for 
deployment. The ART-Ada runtime kernel is an Ada 
library, which is in essence an Ada-based inference en- 
gine. An Ada executable image is produced when the 
machine-generated Ada code and any user-written 
Ada code, if any, are compiled and linked with the 
Ada library. 

While Ada compilers are improving, they still have 
not reached the maturity of C compilers. In fact, be- 
cause of numerous bugs found in the Ada compilers 
used for this project, we could not make some of the 
obvious performance optimizations that could have 
made ART-Ada faster and smaller. It has also been 
observed that both the speed and size of ART-Ada 
vary up to 30% depending on which Ada compiler is 
used. A recent paper discusses the key technical 
issues involved in producing high-quality Ada 
compilers [8]. As Ada compiler technology advances, 
ART-Ada’s performance will improve. 

In addition to the compiler problems, we also dis- 
covered some fundamental issues with the Ada lan- 


guage itself that also affected the performance of 
ART-Ada. Various Ada language issues are being 
studied by the Ada 9X Project team. We believe that 
the issues discussed in this paper should also be con- 
sidered for the Ada 9X standard. In fact, they have 
been presented at the Ada 9X meeting held in 
Washington, D.C. in March, 1990. 

3. Compiler Problems 

Several reports from Ada compiler vendors indicate 
that some Ada programs might run faster than equiv- 
alent C programs. Contrary to these claims, our Ada 
implementation is slower and larger than the C im- 
plementation. Although we believe the main reason is 
the restrictive nature of the Ada language itself, Ada 
compiler bugs also contribute to the poor perfor- 
mance. We used the Verdix Ada compiler on a Sun 
workstation and the DEC Ada compiler on a VAXsta- 
tion running the VMS operating system. 

• The bit-level representation clause or the 
pragma pack can be used to reduce the 
size of data structures. For example, a 
boolean field in a record, which is nor- 
mally a byte, can be reduced to a single 
bit. These features did not work in one of 
the compilers we used; an illegal instruc- 
tion error occurred when the single-bit 
boolean field was referenced. This is prob- 
ably a bug in the code generator. Due to 
this bug, no attempt was made to reduce 
the size of ART-Ada by using these fea- 
tures. 

• In ART-Ada, we reuse several Booch 
components [3]. These software com- 
ponents are used to implement data struc- 
tures (e.g. linked lists and strings) and 
other utilities (e.g. quick sort). Most 
Booch components are implemented as 
generic packages using object-oriented 
design methodology. This means that a 
large number of subprograms are provided 
in each generic package, which may be in- 
stantiated multiple times. Unfortunately, 
one of the compilers does not support a 
feature called selective linking — a linker 
feature that makes it possible to include 
only those subprograms actually used in 
the program. The underlying mechanism 
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used by the compiler is the Unix linker 
(Id), which does not support selective link- 
ing. As a result, whenever a generic pack- 
age is instantiated and included using the 
with statement, all subprograms in the 
package are always included in the ex- 
ecutable image regardless of their actual 
usage. This increases the size of the ex- 
ecutable image. 

• We could not use an optimizer in one of 
the compilers because it generated bad 
code. 

4. Dynamic Memory Allocation 

Due to the dynamic nature of expert systems, it is 
necessary to allocate memory dynamically at runtime 
in ART-Ada. In Ada, new is used to allocate memory 
and unchecked —deallocation, to deallocate it. Our 
experiment shows that the average overhead of new in 
the Verdix compiler is about eighteen bytes, i.e. every 
time new is called, an extra eighteen bytes are wasted. 
This result is obtained by using a program that al- 
locates the same data structure multiple times using 
new and measuring its process size with the Unix 
command “ps aux". We repeated the same experi- 
ment using several data structures of different size. 
According to Verdix, new eventually calls malloc. We 
tried similar experiments using the Sun C compiler. 
The average overhead of malloc was about eight 
bytes, which was significantly smaller than that of 
Ada. It is not clear why it is necessary to add extra 
ten bytes to every malloc. The only information 
needed to call free is the size of the memory, which 
can be obtained from the data type used to instan- 
tiate the generic procedure unchecked —deallocation. 
The exceptions are unconstrained arrays and variant 
records whose size can vary. For these data types, it 
would be necessary to add four bytes to store the size 
information. The actual measurement results are 
summarized in Tables 1-1 and 1-2 in Appendix I. Units 
in these tables are bytes. The C and Ada program 
used are shown in the Appendix H. 

The real problem with this overhead is that in ART- 
Ada new is called very frequently to allocate relatively 
small blocks while in ART-IM (Inference’s C-based ex- 
pert system tool), malloc is called only to allocate 
large blocks (e.g, 100 Kbytes). In order to achieve 


maximum time and space efficiency, ART-IM has 
been optimized in ways that are not portable to Ada. 
For example, the type cast feature of the C language 
has been used both to optimize data structures and to 
implement an internal memory manager. ART-IM’s 
memory manager maintains its own free lists and 
handles all allocation and deallocation requests from 
the ART-IM kernel; it allocates large blocks of 
memory from the system, and then fulfills individual 
(relatively small) requests for storage from the large 
blocks. As storage is released, it is added to inter- 
nally maintained free lists; the blocks themselves are 
never released back to the system. There are several 
advantages to this approach: 

• The free space is managed in a common 
pool by a single facility and is available 
for allocation of arbitrary data types by 
using the type cast capability in C. 

• The overhead of this approach consists of 
a fixed overhead and a very small in- 
cremental overhead for each large block. 

The fixed overhead is 1 Kbyte. Internally, 
all small blocks freed from ART-EM are 
maintained in free lists. There are 256 
free lists, each of which holds memory 
blocks with different sizes. All blocks in a 
free list are of the same size. The head of 
these linked lists consumes 4 bytes. There- 
fore, the total overhead to maintain these 
linked lists is only 1 Kbytes. The sub- 
sequent items in these linked lists store the 
next pointer within the small block itself, 
which results in absolutely no overhead. 

When a large block (e.g. 100 Kbytes) is al- 
located from the operating system, it is 
maintained in a linked list. Each item in 
this linked list consumes 12 bytes, and 
therefore the overhead is only 12 bytes per 
every 100 Kbytes, which is negligible. 

• It is faster than using system routines for 
small requests. 

The success of ART-IM’s use of type casting relies 
on other features of the C language definition: there is 
a direct' correspondence between addresses and pointer 
types; the mapping between data types, including 
structures and arrays, is well defined and straightfor- 
ward. Ada does provide a facility for converting be- 
tween data types, although this feature has intention- 
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ally been made difficult to use. In order to convert 
from one data type to another, the generic function 
unchecked ^conversion must be instantiated for each 
conversion required. The implementation of a type 
cast capability in Ada is insufficient to implement the 
ART-IM features described above, however. No cor- 
respondence is guaranteed between the type 
SYSTEM.ADDRESS and Ada access types. Indeed, 
on some implementations the underlying represen- 
tation is different for addresses and access types. The 
constraint checking requirements of Ada require that 
the representation of many objects include descriptor 
information. The format of these descriptors is not 
defined by the language. Hence, it is impossible to 
implement the ART-EM style memory manager in Ada 
using unchecked ^conversion. 

Another related problem was how to port C code 
similar to the one shown below to Ada. In this ex- 
ample, the & operator is used to resolve the pointer 
reference at compile time through the static array in- 
itialization. C code similar to this example is used to 
convert the .ART-IM internal data structures into C 
source code. 

struct foo < 
long *bar ptr; 

>; 

struct bar < 


>; 

struct bar barl[10] = < ... >; 

struct foo fool [10] = { 

{*barl[5]>, /* fool [0] points to barl [6] */ 


>; 

There are two problems in implementing this in 
Ada: 

• As mentioned earlier, 

unchecked ^conversion is not as flexible 
as the & operator. 

-• Even if it is possible to emulate the & 
operator with unchecked^ conversion } it is 
not possible to free these data structures 
using unchecked _deallocation because 


they are not created dynamically through 
new. 

As a consequence, we had to create all data struc- 
tures dynamically using new. To resolve the pointer 
references, we used the following method: 

1. When a data structure is created, its 
pointer value returned by new is stored in 
a temporary pointer array. 

2. When a data structure has a pointer refer- 
ence, the index of the temporary pointer 
array and the data type of both referencer 
and referencee are stored in a cross refer- 
ence table for later processing. 

3. After all data structures are created, the 
cross reference table is processed. The ac- 
tual pointer value is fetched from the 
referencee pointer array and stored in the 
referencer. 

4. After all pointer references are resolved, 
the temporary pointer arrays and the cross 
reference table are freed. 

The disadvantage of this approach is that large 
blocks of memory must be allocated and freed at run- 
time. The size of the cross reference table could be 
quite large. In fact, we could not use a 16-bit integer 
as an array index because it overflowed on large ap- 
plications. 

The problems of dynamic memory allocation in Ada 
can be summarized as follows: 

• The direct use of new and 
unchecked _deallocation is the only 
dynamic memory management method 
available in Ada. The problem with this 
method is that new incurs a fixed over- 
head associated with each call and it is 
called very frequently to allocate a rela- 
tively small block for an individual data 
structure. It results in a performance 
penalty in size and the slower execution 
speed. This is also aggravated by the poor 
implementation of new in the Ada com- 
piler. 

• The existing Ada features, new , 
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unchecked _ deallocation, and 

unchecked^ conversion, are too restrictive 
and totally inadequate for a complex sys- 
tem that requires efficient memory 
management. More flexible features (per- 
haps in addition to the existing ones) 
should be provided. This is particularly 
important in embedded system environ- 
ments that impose a severe restriction on 
the memory size. 

5. Other Language Issues Related 
to Performance 

The issue of dynamic memory management is, we 
believe, by far the dominant factor for the overhead 
in ART-Ada performance compared with that of 
ART-IM. Other issues in the Ada language that also 
contribute to the overhead are summarized below^ 

• ART-EM has an interpreter (similar to a 
Lisp interpreter) that calls a C function 
using a C function pointer. To emulate 
ART-IM’s function call mechanism, the 
Ada code generator automatically 
generates Ada source code for a procedure 
called FUNCALL that has a large case 
statement. This case statement contains 
all the Ada subprograms that are called 
from an ART-Ada application. Each sub- 
program is assigned with an ID number. 

To call an Ada subprogram, the procedure 
FUNCALL is called with a subprogram ID 
number. While it may cause maintenance 
problems, the use of function pointers can 
provide better performance than the use of 
the Ada case statement. 


• In C, bit operations (e.g. bitwise exclusive 
OR, bitwise shift operations, etc.) are of- 
ten used to implement efficient hashing al- 
gorithms. These operations are directly 
applied to an integer, a float or a pointer 
value to produce a hash code. In Ada, bit 
operations are provided through logical 
operations on packed arrays of booleans. 
These operations, however, cannot be ap- 
plied directly to a value of another data 
type (e.g. integer or float). 

• Ada strings are stored in a record with a 


length field in ART-Ada. A generic string 
package from the Booch component 
library is used for internal string storage 
and manipulation [3]. Since 

STANDARD. STRING is used for ail 
public interfaces, a Booch string is con- 
verted to STANDARD. STRING or vice 
versa. It would be more efficient if the 
standard Ada string is one with a length 
specification that can be manipulated 
easily using a set of predefined standard 
string operations. 

6. Portability 

Although Ada is quite portable (probably more port- 
able than C), Ada is not 100% portable. 

• Since the development environment of 
ART-Ada is written mostly in C, an Ada 
binding is developed to interface it with 
Ada. We found it extremely hard (if not 
impossible) to write portable binding code 
for multiple compilers running on multiple 
platforms. Pragmas for importing and ex- 
porting subprograms are not portable. 

The parameter passing mechanism be- 
tween Ada and C is not standardized. Be- 
cause of this, a mechanism for string con- 
version between Ada and C is not port- 
able. 

• The standard syntax for most pragmas are 
not defined in the Ada Language Reference 
Manual. Consequently, the pragma syntax 
often varies among different compilers. 

• No standards exist for INTEGER, 

FLOAT, LONG _ INTEGER, 

LONG _ FLOAT, SMALL _ INTEGER, 

SMALL _ FLOAT, etc. ART-Ada sup- 
ports 32-bit integers and 64-bit floats in- 
ternally. We had to define 

INTEGER _ TYPE and FLOAT _ TYPE 
as subtypes of whatever a compiler defines 
as such. For example, in the Verdix com- 
piler STANDARD. FLO AT is 64-bit while 
in the DEC compiler 

STANDARD.LONG_ FLOAT is. It might 
be better to define our own INTEGER and 
FLOAT types. It is slightly more con- 
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venient, however, to use existing data 
types defined in the package STANDARD 
because operations on numeric types are 
predefined in the package STANDARD. 

• Since the math library, which is part of 
the standard C language, is not part of 
standard Ada, it is hard to write portable 
Ada code that uses math functions. 

• The representation clause is not portable 
because different Ada compilers and 
hardware platforms may use a different 
memory boundary. 

• Some code is simply not portable. For ex- 
ample, in ART-Ada, a public function is 
provided to invoke the operating system 
commands. Obviously, the implemen- 
tation of this function is not portable 
among different operating systems. 

• Different Ada compilers or even different 
versions of the same compiler often have a 
different set of bugs. It may be necessary 
to maintain multiple versions of the same 
code to work around them. 

In C, conditional compilation facilitated by 
preprocessor directives (e.g ^define and #if) allows 
maintaining a single source file for multiple platforms. 
In Ada, no such facility exists, and multiple files may 
have to be maintained for multiple platforms. Since 
we had to maintain ART-Ada on multiple platforms 
(possibly on multiple compilers on the same 
hardware), we did not want to maintain multiple files. 
At first, we were going to write a preprocessor in Ada 
or in C. After some experiments, however, we found 
the C preprocessor (cpp) on a Sun quite adequate for 
preprocessing the Ada master File with cpp macros 
embedded (e.g. #if, #endif, etc.). 

The master File includes Ada code and appropriate 
cpp commands for multiple platforms : 

#1 f VERDIX 

subtype FL0AT_7YPE is FLOAT; 

#endlf 

#lf VMS 

subtype FLOAT JTYPE Is LONG_FLOAT; 

#endif 


We define app as follows: 

/lib/epp $1 $2 $3 $4 $5 $6 $7 | grep -▼ ,A #' 

Then, we execute the following commands: 

app -DVERDIX foo . a . master > foo.a 
app -DVMS foo. a. master > foo ada 

The first one creates a file for the Verdix compiler 
on a Sun, and the second, for the DEC Ada compiler 
on a VAX/VMS. 

The problem with this is that the Ada master file is 
still not a compilable Ada file and has to be 
preprocessed manually. We also have to maintain 
multiple Ada files generated by cpp. It would be bet- 
ter if the preprocessor is part of the standard Ada 
language so that only a single source file is main- 
tained and processed directly by the Ada compiler. 
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I. Memory Allocation Benchmark Results 


Item Size 

Item Count 

Ideal Size 

Actual Size 

Overhead 

Overhead/Item 

8 

100,000 

800 K 

2496 K 

1696 K 

16.96 

16 

100,000 

1600 K 

3312 K 

1712 K 

17.12 

24 

100,000 

2400 K 

4128 K 


17.28 

32 

100,000 

3200 K 

4808 K 



8 

50,000 

400 K 

1408 K 

1008 K 

20.16 

16 

50,000 

800 K 

1816 K 

1016 K 

20.32 

24 

50,000 

1200 K 

2224 K 

1024 K 

20.48 

32 

50,000 

1600 K 

2496 K 

896 K 

17.92 

Average 

N/A 

N/A 

N/A 

N/A 

18.29 


Table I-ls Overhead of Dynamic Memory Allocation using new in Verdix Ada 


Item Size 

Item Count 

Ideal Size 

Actual Size 

Overhead 

Overhead/Item 

8 

100,000 

800 K 

1600 K 

800 K 

8.0 

16 

100,000 

1600 K 

2384 K 

784 K 

7.84 

24 

100,000 

2400 K 

3160 K 

760 K 

7.60 

32 

100,000 

3200 K 

3944 K 

744 K 

7.44 

8 

50,000 

400 K 

816 K 

416 K 

8.32 

16 

50,000 

800 K 

1208 K 

408 K 

8.16 

24 

50,000 

1200 K 

1600 K 

400 K 

8.0 | 

32 

50,000 

1600 K 

1922 K 

392 K 

7.84 

Average 

N/A 

N/A 

N/A 

N/A 



Table 1-2: Overhead of Dynamic Memory Allocation using malloc in Sun C 
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II. C and Ada Programs for Memory Allocation Benchmark 


^include <stdio.h> 

main () 

< 

int i; 

for (1=0; i< 100000 ; i++) { 
malloc(32) ; 

> 

getcharO; /* measure the process size at this point */ 


with TEXT_I0; 
procedure TEST_NEV is 


type ELEMENT is 
record 


FIELD 1 : 

INTEGER 

FIELD2 : 

INTEGER 

FIELD3 : 

INTEGER 

FIELD4 : 

INTEGER 

FIELDS : 

INTEGER 

FIELDS : 

INTEGER 

FIELD7 ; 

INTEGER 

FIELDS : 

INTEGER 

end record 

; 


4 byte 
4 byte 
4 byte 
4 byte 
4 byte 
4 byte 
4 byte 
4 byte 


type ELEMENT_PTR is access ELEMENT; 

PTR : ELEMENT_PTR; 

CHAR : CHARACTER; 

begin 

for I in l.. looooo loop 
PTR := new ELEMENT; 
end loop; 

TEXT_I0.GET(CHAR) ; — measure the process size at this point 

end; 
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